home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990725-20000114
/
000220_news@columbia.edu _Thu Oct 21 16:57:08 1999.msg
< prev
next >
Wrap
Internet Message Format
|
2000-01-13
|
3KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA03332
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 21 Oct 1999 16:57:08 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA21829
for kermit.misc@watsun.cc.columbia.edu; Thu, 21 Oct 1999 16:33:40 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: kermit-support@columbia.edu (Kermit Software Support)
Subject: Re: File type attributes in K95
Date: 21 Oct 1999 16:33:30 -0400
Organization: Columbia University
Message-ID: <CMM.0.90.4.940537928.fdc@watsun.cc.columbia.edu>
To: kermit.misc@columbia.edu
> I am sending the dialing script and startup files, along with the
> debug.log and packet.log for this problem. The only other commands
> given to K95 were LOG DEBUG ON and LOG PACKETS ON.
>
OK... The login script is the standard thing generated by the Dialer.
Nothing in it would explain any kind of text/binary reversal. The
K95CUSTOM.INI file is vanilla (but has that odd printer thing which is
not relevant here...)
> After sending the file from Kermit-TSO as TEXT, I escaped out and SET
> FILE TYPE TEXT on K95, then connected and sent the same file as binary.
>
> In each case the file transfer display on K95 showed the wrong type.
> I can't honestly tell you if the problem is new with Kermit TSO 4.3.3, I
> don't currently have access to any older versions. Previously, I used
> C-Kermit for OS/2 (191?) and Kermit-TSO (4.3.1 I think - I remember
> fixing the PDS prefix bug). I don't remember encountering this problem.
>
I think the mainframe business is a red herring. The logs show that
mainframe Kermit is doing everything right. When you send in text mode,
mainframe Kermit announces text, sends legible ASCII text like:
DCB=(RECFM=VB,LRECL=255,BLKSIZE=0)
(heavens, JCL!) and K95 receives it as text, in text mode. When mainframe
Kermit sends in binary mode, it announces binary, and sends raw EBCDIC,
which of course looks like gibberish in ASCII:
~&@#N~$prvpp#Oaa~-@&D&C&B#~M#NYECFT~eB&kSYECS~upp&kBSRbIiE
and K95 stores it that way (after decoding the Kermit escapes).
> I have done some further testing. I created a file with all possible
> hex characters and transferred in al possible modes.
>
> I found that even though K95's transfer display reported TEXT (Latin1 =>
> CP437), it did not translate any characters on a binary transfer, so the
> problem is probably in the transfer display code, rather than the
> attribute recognition.
>
That seems to be it. This is 1.1.17, right? If I'm not mistaken, we did
fix some bugs in that area, and so our working copy shouldn't do this. If
you'd like to try it, let me know.
> BTW: Can I put in a request for pipe support at the K95 command line?
> It wouldn't let me enter 'SHOW PRINTER > printer.txt' or 'SHOW
> ATTRIBUTES > problem.txt'
>
This is probably not in the cards any time soon, but of course you can
always scroll the screen back and copy & paste with the mouse.
- Frank